The present invention relates in general to migration of process instances. In particular, but not exclusively, the present invention relates to migration of process instances in a workflow system.
A workflow system, or a workflow management system (WFMS), provides a foundation for defining and executing business processes. A business process defines tasks that need to be followed in a certain order and subject to certain conditions. As an example of a business process, consider administrative processes such as the handling of an expense account form. An employee needs to fulfill the form and attach necessary receipts. Thereafter the form is routed to the manager for approval, and in the end the accounting department checks the details and reimburses the employee for the approved expenses. All business processes are not of financial nature. Consider, for example, the process of a database administrator for backing up and restoring a database system.
A workflow system provides functionality for defining business processes and for executing them. A business process is represented by a schema (process model), which defines a set of activities corresponding to the real-life tasks. The schema defines also the order in which the activities are to be executed and the conditions for executing a certain activity. The activities may represent either tasks conducted by software or tasks conducted by users. Different equipment with different software can be used to perform the tasks.
FIG. 1 shows, schematically, most relevant parts of a workflow system. A schema is created in an editor 101 and stored in a schema store 102, called Repository in FIG. 1. A user can create the schema, for example, using a specific workflow definition language, such as Business Process Execution Language (BPEL). The schemas may be created and stored beforehand, and then deployed to a template store 104 in a deployment step 103. A deployed process schema is usually also called a process template. At runtime, the workflow engine 105 reads the template information 104, creates and stores instance data to an instance data repository 106 and navigates the process instances.
The deployed schema (template) storage 104 may contain multiple versions 107 of a schema. The workflow engine 105 may navigate instances for each of these template versions with different states 108. In this versioning approach a process instance 108 is always bound to the version of the process template 107 that it was created for.
The versioning approach is not very flexible because of the strong association from process instances to process templates. When a process schema is modified, and deployed as an additional process template version, the existing process instances are insensitive to the modifications, even if the modifications might be relevant also for already existing process instances. Other approaches, such as schema-evolution and ad-hoc workflow, do not have this association. Using these approaches, if a process instance is migrated to a new version of the process template, the process instance is associated with multiple templates. This has several different problems: With ad-hoc approaches, each process instance needs to be dealt with individually, creating a significant handling problem in a production system with large numbers of concurrent process instances, and a large number of process templates, one per process instance. With current schema evolution approaches, on the other hand, in order to ensure consistency of the changes so that all the process instances stay in accordance with the general objectives behind the changes, they impose very restrictive rules about the nature of changes, effectively preventing the migration of existing process instances to a new process template version for many practically relevant cases.
Migration of process instances was discussed above in connection with workflow systems, but the migration of process instances may be relevant also in other information technology systems and applications.
Embodiments of the present invention aim to provide a new, more flexible approach that allows to automatically migrate process instances to an updated process template for many practically relevant cases, while not requiring to touch each process instance individually.